home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3217 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.0 KB  |  95 lines
  1. Path: chaos.aoc.nrao.edu!usenet
  2. From: Chris Flatters <cflatter@nrao.edu>
  3. Newsgroups: comp.object,comp.databases.object,comp.lang.java,comp.lang.smalltalk,comp.lang.c++,comp.lang.eiffel,comp.lang.objective-c,comp.software-eng
  4. Subject: Re: Data-driven vs. Behavior-driven OO Methods: a Non-Issue?
  5. Date: Mon, 22 Jan 1996 13:59:55 -0700
  6. Organization: NRAO
  7. Message-ID: <3103FACB.32F9@nrao.edu>
  8. References: <4dhop7$3aj@suez.iconcomp.com> <86n37i3ie4.fsf@beowulf.gamp.hacom.nl>
  9. NNTP-Posting-Host: laphroaig.aoc.nrao.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0b5 (X11; I; SunOS 5.4 sun4c)
  14.  
  15. albert@gamp.hacom.nl wrote:
  16. > 
  17. > Desmond F. D'Souza writes in  <4dhop7$3aj@suez.iconcomp.com>
  18. > 
  19. > > There has been much controversy and discussion about methodologies
  20. > > that are behavior-driven vs. those that are data-driven, with
  21. > > OO-"purists" arguing vehemently against data-driven approaches. In
  22. > > this paper, we suggest that the difference may be smaller than often
  23. > > thought, if we adopt a simple definition of a "type model".
  24. > 
  25. > > Paper available:
  26. > > <A HREF="http://www.iconcomp.com"> On the Web</A>
  27. > 
  28. > I have got the paper, (first one in a series of 1)
  29. > 
  30. > [...]
  31. > 
  32. > I'm sorry to say so, but it IS a nice story about nothing. Some new
  33. > words and myths are introduced, which are solved by renaming them.
  34. > 
  35. > One example is about a "Stack", which IS a relevant one.
  36. > 
  37. > That examples says: do not just say a stack is " ....", be specific.
  38. > 
  39. > I thing we ALL know that. It is like old good programming:
  40. >                 printf() should behave as printf!
  41. > But there is hardly a need to specify that. So is a stack. it should
  42. > behave like a stack! So all counter-examples of the paper that decribe
  43. > a FIFO, ar a list or ... are no stacks!
  44.  
  45. Something is being missed here.  The phrases "printf() should
  46. behave as printf()" and "a stack should behave like a stack"
  47. are deceptively simple.  In reality they are both references 
  48. to fairly detailed and precise specifications. 
  49.  
  50. If we say that printf() should behave as printf() we are actually
  51. saying that printf() should behave as it is described in ANSI/ISO
  52. 9899-1990 (the ANSI/ISO C standard).  The phrase "printf() should
  53. behave as printf()" is actually a shorthand for approximately
  54. two pages of legalistic text that defines (precisely, we hope)
  55. what printf() should do.
  56.  
  57. In the case of a stack we are not referring to an explicit
  58. specification as in the case of printf() but are relying on the
  59. facts that a stack has well defined characteristics in the context
  60. of computing and that people working with software all share
  61. the same idea of what a stack is (at least in its more general
  62. aspects).
  63.  
  64. In analysis and design we rarely have the opportunity to reference
  65. external definitions (either explicit specifications such as
  66. that for printf() or implied specifications as for a stack).  If,
  67. for example, we have a design that refers to a Document type, 
  68. everyone working on the design may not understand the concept of
  69. a document in the same way.  We must therefore define the concept
  70. a document (in the context of our system) with a sufficient degree
  71. of precision that anyone working with our design understands a
  72. document to be the same thing.
  73.  
  74. Of course there is nothing really new here.  A great deal of work
  75. has been done on developing notations and methods for constructing
  76. precise definitions in computing (including formal notations such
  77. as Z and the Eiffel/BON notion of programming by contract).  I
  78. regard it as a good thing that developers of OOA/OOD methodologies
  79. are beginning to pay attention to the need for precise definitions.
  80.  
  81. > [...]
  82. > 
  83. > But it is also true, some more complex "objects" shoul be described
  84. > better. But do not make the mistake to solve this by specifing it by
  85. > other "informal words" That just hides the problem, it doen't solve
  86. > it.
  87.  
  88. The paper clearly uses formal predicate calculus to specify behaviour.
  89. This is far from using "informal words".
  90.  
  91. --
  92.  
  93.     Chris Flatters
  94.     cflatter@nrao.edualbert@gamp.hacom.nl wrote:
  95.